終於寫到最後一篇了，從 embeddedServer 跑起來一路到打包進容器，起一台真的 server 做 end to end 測試，todo-api 這個小專案跟著跑了 30 幾天，這篇單純講一些心得

原本以為會比較簡單，結果沒有

寫完上一個 手刻 Ktor 的系列 之後，想說這次改用真的 Ktor 來開發，應該會比較簡單一點，機制都自己做過一遍了，剩下的不就是照著文件把東西裝起來嗎 ? 結果反而沒有

也因為大概了解底層的一些原理，看到某個行為跟想的不一樣，就會忍不住想弄清楚為什麼，所以踩的坑比直接拿來用的人還多一點

• day 18 裝官方 DI，碰到的幾個問題都不在文件裡，最後是翻原始碼才確定的

• day 33 補一個健康檢查，第 1 版就差點打破 day 24 那個「給了假 repository 就不會碰資料庫」的保證

• day 34 量下去才發現 stop() 的 grace period 保護的是 handler 跑不跑得完，不是回應送不送得到。要是只把它當成一個黑盒子用，這些事大概都不會去碰，也就不會知道

另一個原因是 Ktor 本身夠小夠輕，很多東西其實沒有實作或是沒有內建，這也不能怪它，JetBrains 原本就是要拿它來當輕量的 server 用，官方 DI 拖到 3.2 才加進來也就不奇怪。所以要自己實作，或是要改預設行為的時候，多多少少會碰到一些神奇的現象，不然就是要繞遠路才能達成想要的目的

角色授權是一個例子，day 28 的 Ktor 只給你認證，認證過之後這個人能不能做這件事，要自己寫一個 plugin 掛進去，day 32 換成 cookie 之後又是另一個，install(Sessions) 最短的範例裡沒有簽章，不簽的話手工組一個 cookie 就能拿到 admin 才能拿到的回應，transform 那一段要自己補上去，這些都不是 Ktor 做錯了什麼，它只是把決定留給你，麻煩的是你得先知道有這個決定要做

手刻完再用真的 Ktor

上一個系列的收尾是站在手刻完成的那一頭回頭看 Ktor，這次剛好反過來，用完一輪再回頭想 Relix

手刻的時候，為了證明機制做得出來，專案越小越好，Relix 講 plugin 系統那篇 的 main() 裡就 2 條路由，一條正常回應，一條丟例外，這樣就夠了，這邊完全相反，為了看到機制接起來會怎樣，專案得夠大才行，到 day 26 裝上認證的時候，module() 裡已經有一排 install 疊在一起，這時候順序這件事才開始咬人。一個只有 3 個 middleware 的示範專案，兩邊看起來一模一樣，差別要到專案長大之後才看得到

另一個感受是，手刻的時候很容易把認證簡化成「檢查一個 header」，一個 Authorization 進來，比對，過或不過，那是最容易做也最容易測的形狀，到 day 32 瀏覽器導覽送不出 Authorization header，才發現那個簡化不成立，改用 cookie 之後入口有了，一整組新問題跟著進來，連 challenge 的形狀都變了，API 客戶端要的是 401 加一個 header，瀏覽器要的是轉去登入頁，這件事在「檢查一個 header」的模型裡根本不存在，手刻的時候沒碰到，是因為 Relix 的認證從頭到尾只面對 API 客戶端

還有一件事兩邊沒差，框架不會替你決定的事情同樣多，Relix 的 main() 就是 app.start()，跑在 IDE 裡，而 day 33 做的每一件事都在 app.start() 之後，打包、換掉預設用 root 跑的 base image、決定 /health/live 跟 /health/ready 各自該回什麼，Ktor 在這裡給的只有打包那一層，剩下的清單換成任何語言任何框架都一樣，手刻框架的時候我還以為這些是「用了正式框架就有」的東西，結果沒有

對接下來的期待

蠻期待 Ktor 接下來的發展，我覺得輕量好上手真的是它的特點，寫幾行程式碼就可以跑起來，routing {} 裡面加一條路由就是一個端點，這個走向跟後來的 .NET Core 有點像，Minimal API 出來之後也是幾行就能起一個服務

不過 .NET Core 的生態系太完整了，要什麼幾乎都有官方或社群的成熟方案，這樣比其實也不太公平，.NET Core 發展很多年了，之前又有 .NET Framework 的歷史背景，很多東西是從那邊一路帶過來的

Ktor 這邊很多地方還在長，DI 是 3.2 才有的，OpenAPI 那些在 day 29 用的時候還掛著 experimental，希望慢慢地可以更完整一點，讓「要自己補」的清單再短一些

回頭看這個系列的測試呈現

前 2 個系列都是把測試集中放在每篇前面，這次在 day 03 改了慣例，測試程式碼放在對應的實作附近，講到哪個行為就把那個行為的測試放在旁邊，不為了固定版型把證據和說明拆開

寫完之後覺得這個做法比較適合這種「一個專案一路長大」的系列，因為每篇改的東西都散在專案不同的地方，測試如果全部堆在前面，讀者要一直往回翻才知道這個測試在驗什麼，代價是文章的節奏比較碎，一段說明、一段測試、一段實作，交錯著走，有些篇會比較長，另外設定、建置、部署這類主題沒有硬塞測試，改成提供可重現的驗證步驟，照著做就能確認結果，這點我覺得是對的，硬要幫 Dockerfile 寫測試只會讓文章變得很奇怪

最後

有機會的話，接下來想試試看 KMP (Kotlin Multiplatform) 的開發，同樣是 Kotlin，web 後端和 mobile app 的開發體驗到底會有多大的差別，這個蠻好奇的

同步刊登於 Blog

圖片來源：AI 產生